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METHOD AND APPARATUS FOR 
T p EMITTING DATA PACKETS 

p^MftfThe Invention 

5 The present invention relates to methods and apparatus for transmitting 

multimedia in a communication network More partly, the present invention 
relates to methods and apparatus fo, transmuting data packets containing audio 
and video, over a communication network, for example the Internet. 
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Back ground Cif The Invention 
Communication networks, such as wide area networks (WAN), are 
commonly known, and perhaps the fastest growing of these is the internet. One 
internet application, known as multimedia transceiver,' enables users to transmrt 
and receive audio, video and text over the Internet. An example of this 
application, known as Internet telephony client, allows for telephone calls over 
Ihe Internet. ■• 

In accordance with this Internet telephony client, a user dials the 
telephone number of a recipient user via a computer keyboard or the like. When 
the call is established between the users, the Internet telephony client digitally 
samples the voice of one user; temporary stores the samples in a buffer, and 
pa^geTtiTe samples into a data packet^acke^The data packet or packets 
i 5 /are transmitted to a recip_iejrt^u 5 Jngjn IPprotocol. The recipient user 
receives the data ^ckeT^ackets. st rips them o Mhe protocol Readers and 
converts the samples into voice. This methodtealso performed at the caller end 
of the internet connection pathway. Y 

This internet telephony die* exhibits drawbacks in that the voice qualrty 
on both ends of the communication pathway Is poor. Sevejalmejh^haye 
been attempted to imp^ovemisjfOjc^^ 

^AUhe~ sender end. these methods typicallyinvolve always transmitting 
packers that^ebuilt based on the parameters that are necessa.y for insuring the 
audio quality at the receiving side/These parameters can be redundancy, 
packaging schemes and/or patterns and compression type and/or rate. These 
methods exhibited drawbacks in that they did not adjust for changing network 
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whereby ineree S ea In the n««k M conSnued to result In poor 

"* Molar, whan — .cat,*, ware added to these already poor 
quality audio communications, (he network load increased. This increase 
, 1L in turther delay, nofce and disturbance ,n audio, lowerlna » quaWy. and 
freezing of the video image. 

?i.mr« iff ft f T hB '"v*"«^ n 
The present invention overcomes the disadvantages of the prior art by 
10 accountingforthenetworKconditionaandtransmitting audio, typically voice, m 
accordance with the sensed network condrtion. Specifically, the present 
invention allows for thejo jec^nof the net work state and controlling of the b, 
rate imrnMrn^^^S- In orde, lo improve the med.a quality of 

in accortQnce WHH the d6teCted netW0 ' k 
15 atate such that the audio quality of the communication is improved when 

compared to that of the prior art. 

in one aspect of the present invention, there is p.ovided a method for 
transmitting packets over a packed switch netwo*. The network includes a 
plurality of multimedia transceivers for sending and reccing mulfamed* 

20 communications such as audio and video, typically voice. 

The method Includes the steps of providing at least two predefined 
network states to be compared with a monitored network stale, monitoring the 
network slate, selecting one state of the at least two predefined network states 
in accordance with the monitored network state, sampling at least one type of 

25 mediaatatransmitterforprovldlngalleastonemcdiasample.packaging 

network protocol parameters with the at least one media sample Into a packet, 
and transmitting the packet over the network, wherein the number of med.a 
samples in the packet is in accordance with the predefined network state. 
Advantageously, a different type of packaging enables transm.ss.on of 
30 d^erentlongthsofpacketswrthacccdancetothenetworkstate. l his allows fo. 
a bit rate adjustment according to the network available band width and state 
(condition), for Improving received media quality at the receiver. 

In the preferred embodiment of the invention, the steps of proving at 
least two predefined states further includes the steps of analyzing the network .n 
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accordance wM, a. M one type of receiv* MM communication, ^ 
Tn«worK Into a. leas, «wo ne^rk stems, these n*«* «- 
,o the above described predefined network state,, end for each network state. 
rl^ a. leas, one media frame wKh at least one parameter. In ft. manner. 

The invent alsoprcvides an apparatus tor transmitting packets over a 
packed swlteh nelwori< is provided. The apparatus Includes a means for 
providing at least**, predefined network states and at least one predefined 
rnedia construing parameter such as a labia in a memory. The apparatus 

10 further includes a mentor for monitoring a network state, a selector for seletfng 
at least one state of the al least two predefined network states In accordance 
Witt, the monitored network state, a sampling means for providing samples of at 
.east one media type, a packaging means for packaging communication protocol 
parameters with media samples for providing a packet, and q transit for 

15 transmitting the packet, that has been constructed in accordance with the 
detected network state. 

p ri ^f rwrri ption Of Th e Drawings 
The present invention will be described with reference to the 
20 accompanying drawings, wherein like reference numerals and/or characters 
identify corresponding or like components. In the drawings: 

Fig 1 is a block diagram of illustrating the present invention; 

Fig. 2 is a detailed block diagram ot a media transmitter in accordance 

with the present invention; 
25 Fig. 3a is o diagram ot a packet for « first protocol employed in the present 

invention; 

Fig. 3b is a diagram of a packet for a second protocol employed ,n the 

present invention; 

Fig. 4 is a table detailing audio packaging parameters in accordance wrth 

30 Hie network state; 

Fig. 5 is a flow chart of the method of the preferred embodiment of the 

invention; . . 

Fig. 6 is a graph of bit rate versus frames per packet in accordance wrth 

the present invention; and 

P-216H-US 



2.FEB.199ST"14:07 EITPN PEftRL LATZER+C0HEN-2EDEK ,on350 .nu6 

Fig. 7 is a chart of actual bit rate* in «M vrtth the graph of Rg. 6. 

p-^i..j n .^riptior ™ Tha Drawing? 
H g 1 details the present invention In operation with 0 packet switch 
, network 1 fortransmMng a d*a packetor packets. The packets*** neWork 
r t ?.«.dearean^and fa e,an 1 p,..i.couk l bethe,n te rne.. Mufcme^ 
transceivers 2-5. for sending and receding multimedia oommunkation, ovarthe 
network 1, are linked to the network 1 by conventional communication means, 
these communions typically involve muNmedia calls, that include aud* and 
,n video, generated by a transceiver, such as transceiver 6 to another transceiver, 
such as transceiver 4 over the network 1. 

Transceiver 5. Is exemplary of the other transceivers 2-4. All of these 
transceivers 2-5 typically include a transmitter 6 and a receiver 7. The 
transmitter 6 typically inCudcs an audio transmitter 6 (in combination with an 
« audio bit rate controller 18, as below, defines an audio channoi), for transmitting 
au d,o packets over the network 1 art a video fcansmttter 0 (in common wkl, a 
video bit rate contro.ler 20. as below, defines 0 video channel,, for transmttng 
video packets over the network 1. The recerver 7 may include audio and «deo 
receivers (not shown) for receMng media transmissions that include audio and 
video. An example of such a transceiver is a computer program such as 
INTERNET PHONE® from Vocal Tec Communications. Ltd, Herz.Ua. Israel, that 
uses a PENTIUM* or PENTIUM It* based personal computers (PCs), that 
include, audio and video cards and a network communication device or a 
modem to perform Ihe invention. 

Fig 2 shows a block diagram ot the transmitter 0. as in communicate 
with the network 1 . The transmitter 6 Includes the audio transmitter 8. v,deo 
transmitter 8 and a selecting means or selector 10. for controlling bit rate 
between the audio » and video 9 transmitters, for transmission of packets 
(detailed below) over the network 1 . 
30 The audio transmitter 8 includes an audio sampling device 1 1 . that 

samples the audio, such as voice from the user (U). This audio samp.ing device 
11 is opcrably coupled with a composing means 12, that communicates wrth a 
packaging means 13. 
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The compressing means 12 include, a voice tftt detector (VAD) 14 
and an audio compress 16. The vo.=e «M, detect 14 detecte vo,ce aeMy 
and transfers the voico sample, to the audio compressor 15. T» onB 
compter 15 fcnoflons to compress voice sample, end to prov.de at least one 

audio frame. 

The packaging means 13 includes audio packaging means 16. 
redundancy packaging mean* 17 and a Internet Protocol (IP) packaging means 
IB The audio packaging means 16 serves to package compressed aud.o 
frarnes into a packet, while the redundancy packing means 17 is for packagmg at 
least one redundant audio frame, corresponding to the packaged audio frame. 
Tho IP packaging moans 18 packages IP communication protocol parameters, 
for example, an IP protocol header, for providing a packet and transmitting th.s 
packet over the network 1, typically the Internet, to the transceiver 4. Th.o 

packaging is typically a packaging ot audio frames in a single packet or mult-ple 
packets, as produced by the audio compressor 15 (and corresponding vrdeo 
compressor 24, for video). Packaging Into single or multiple packets typically 
involves using one or more (but at least one) communication protocol 
parameters, such as a number of frames per packer, redundancy or a 
redundancy scheme, for input to the IP packaging means 18. 

The video transmitter 9 includes a video sampling device 23, a vrdeo 
compressor 24 and packaging means 25. The video sampling device 23 
samples the video signal and inputs the video samples to the video compressor 
24 The video compressor 24 compresses the video samples and provrdes at 
least one video frame. The packaging means 25 package the video frame wrth 
the communication protocol headers, for example. IP protocol headers, to 
provide a packet or packets, that will be transmitted over the network 1 . 

The selecting means or selector 10 includes media bit rate controllers, 
here, an audio bit rate control device 19 and a video bit rate control device 20 
and an allocator 21 . These media bit rate controllers conlrol transmission epeed 
and tire network load in accordance with the monitored network state. The 
allocator 21 is operably coupled to a network monitor 22, that mon-tors The 
network 1. for its condition, in real time, by receiving the network state, and at 
to* one of the media bit rate controllers. The network monitor 22 provides the 
network state lo the selecting means 10. This in turn allows the selecting means 
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1 o to control the video compressor 2A for packaging constructing parameters 
with video samples to provide best video quality at the transceiver 4. It also 
allows the allocator 21 in the selecting means 10 to select tho monitored network 
state that is most similar to one predefined network state, from a series of 
5 network states, stored in the allocator 21 . 

The allocator 21 may also include a data storage device (for storing 
databases, data, and the like), a data processor, such as a microprocessor or 
other computing or data processing means. Also the data storage dcv.ee and 
data processor could be within the selecting means 10, external to the allocator 
21 and could also be external to the transmitter 6. The audio bit rate control 
dev.ee 19 or video bit rate control device 20 receives commands (in the form of 
data or signals) from the allocator 21 to raise or lower the respective bit rates 
(detailed below). Additionally, the audio bit rate control device 19 and video bit 
rate control device 20 include hardware and software for adjusting the bit rate 
15 transmission to the available bandwidth of network 1 . 

A signal from the allocator 21 inputs control data to the audio bit rate 
controller 19. This audio bit rate controller 19 controls the audio compressor 15, 
audio packaging means 16 and the redundancy packaging, means 17 of the 
audio transmitter 8. for packaging the parameters which result the best aud.o 

20 quality at the receiver 7 (Fig. 1 ). 

Fig. 3a Is a description of a packet SO with accordance with a real time 
protocol (RTF). RFC 1889 as described in Schulzrinne, et al.; "RTP: A Transport 
Protocol fo. Real-Time Applications", Network Working Group. Standards Track 
RFC 1809, January 1906 (hereinafter. "Standards Track-RFC 1889"), available 
at htto://www.ietf.org/rfc/rfcl 889.txt. and incorporated by reference in its entirety 
herein. The packet 50 includes a plurality of fields of 32 bits. 

n» first five fields. Version field (V), Padding field (P). extension field (X), 
CSRC count field (CC) and the marker field (M) are described in Standards 
Track-RFC 1889. 

A payload type (PT) field 52 Identifies the format of the RTP media data 
and determines its interpretation by an application. 

A sequence number field 54 increments by one for each RTP data packet 
sent and may used by the receiver to detect packet loss to lestore packet 
sequence, the sequence number field 54 is 18 bits field. 

f: P-2163-US 



25 



80 



2. FEE. 1999 .14:08 



EITftN PEftRL LATZER+CGHEN-ZEDEK 

# 



. on 350 .nug 



A timestamp field 57 Includes 32 bite and reflects the time of the sampling 
instant of the first byte of the presont packet resampling instant must be 
driven from a clock that increments monotonlcally and linearly in time to allow 
synchronization and jitter calculation of media samples. 
5 A synchronization source identifier field 58 includes 32 bite and identifies 

the synchronization source. 

The last field is a media field 59 which includes compressed media 
samples The compressed media samples may be audio or video samples. In a 
preferred embodiment, a G.723 codec Is used with a bit rate of 6400 bits per 
10 second. The audio samples are arranged in frames. Each frame includes 240 
audio samples which are compressed into 24 bytes wherein each byte Includes 8 
bits. The number of media frames may be varied in accordance with the 
monitored network state. 

Fig 3b Is a description of a packet 70 with accordance to a real time 
15 protocol (RTP), RFC 2198. as described in Perkins et al.; "RTP Payload for 
Redundant Audio Data". Network Working Group Standards Track RFC 2198. 
September 1997 (hereinafter, "Standards Track - RFC 2198"). available at 
http /A W ww.letf.o.g/rf C /rfc2198.txt, and incorporated by reference in its entirety 
herein. The packet 70 includes a plurality of fields of 32 bite, and Is detailed at 
20 page 8 of Standards Track-RFC 21 98. 

The first five fields. Version field (V « 2). Padding field (P). extension field 
(X) CSRC count field (CC * 0). sequence number field, timestamp field and 
SSRC field and the marker field (M) are similar to thosa described for RFC 1 889, 
in Fig 3a above, and in Standards Track - RFC 1889. 
25 The packets 70 containing a primaiy data block 71 . and a single block of 

redundancy data 72 as defined In the Standards Track-RFC 2198 is illustrated. 
The description of the other fields is as follows: 

The bits in the header 73 (outlined In solid lines in Fig. 3b) are specified as 
follows: 

30 The first bit in the header 73 indicates whether another header bock 

follows. If "1". further header blocks such as block PT=7 (block 74a) follow, if "0" 
this is the last header block, such as block PT=5 (block 74b). 

Block "PT=7" (block 74a) is the RTP payload type which may be audio or 
video and which compressed in primary data block 71 . 
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The next block in the header 73 is the timestamp offset block 75. th.s 
block relative to the timestamp given in RTP header, as described in Fig. 3a. 
The use of an unsigned offset implies that .edundant data must be sent after the 
primary data, and is hence a time to be subtracted from the current timestamp to 
detennine the timestamp of the data for which this block is the redundancy. 

1 he next block is block length 76, which indicates length in bytes of the 
corresponding data block excluding header. Fhe header for the primary (final) 
block comprises only a zero F bit. and the block payload type information PT*5 
(block 74b). The final header Is followed, immediately, by the data blocks, stored 

LO in the same order as the headers. 

1 he choice of encodings used should reflect the bandwidth .equipments 
ot those encodings. It is expected thatthe redundant encoding shall use 
significantly less bandwidth that the primary encoding: the exception being the 
case where the primary is very low-bandwidth and has high processing 
requirement, in which case a copy of at least one audio or video frame, stored m 
the primary data block 71 may be used as the file redundant data 72. 

The use of multiple levels of redundancy is rarely necessary. 1 lowevcr, .n 
those cases which require it, the bandwidth required by each level of redundancy 
is expected to be significantly less than that of the previous level. 

Network behavior is analyzed statistically and is based on detected 
network behaviors. Network states are defined, where in each state, a set of 
constructing parameters for constructing the packet needs to be determ.ned. 

Bit rale control is in accordance with the Table of Fig. 4. In th.s table, 
there are four predefined network states: Regular. Loss, Delay, end Loss + D 
(Loss plus Delay), to which the actual detected network state is matched. Within 
each network state are bit rates for emission, and corresponding quality 
states or quality degrees for the network state at the bit rate. These quality 
states (quality degrees) are defined as follows: H = high quality, the best quality 
state, transmitting one frame per packet and redundancy, wherein thore » packet 
30 loss in the network; S = sufficient quality, the second best quality state (quality 
degree), transmitting more than one audio frame in a packet; and NS * 
non-sufficient quality, the least quality of the three quality states, packet loss 
without redundancy. This Table (Fig. 4) was obtained by analyzing the network 
in accoidance with a received audio communication, characterizing the network 
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into at least two states, and for each network state, packaging a number of media 
frames in accordance with the network state. 

The apparatus and systems detailed above perform methods for 
transacting packets in accordance with the present invention. These methods 
improve on the prior art transmitting methods, for they provide superior aud.o 
quality at the receiving side. An exemplary method, resuming in a transmiss-on 
such a multimedia call from transceiver 5 to transceiver 4 over the network 1 w..l 
be described now in accordance with Fig. 5. 

In Fig. 5, there is shown the method of the present invention. "Ihis method 
may be performed for example, to include stages of bit rate adjustment in 
accordance with the network state. A first stage is a first or coarse adjustment of 
the bit rate, while the second stage is a second or fine adjustment of the brt rate. 
This two stage bit rate adjustment, for example, is performed by algorrthms. 

A first algorithm is employed to detect the nelwork state and perform a first 
or coarse adjustment of the bit rate in correspondence thereto. A second 
algorithm serves to cause a second or fine brt rate adjustment, to Increase or 
decrease bit rate upon detection of congestion in the network. 1 . The brt rate, 
having been subject to a first (coarse) adjustment, and a second (fine) 
adjustment, if necessary, is then allocated among the audio and video channels 
by the allocator 21. such that the audio transmission is made with a proper bit 
rate allocated thereto in the preferred embodiment. It is preferred that th.s 
exemplary method be performed in intervals of 5 seconds. 

At step 202, the interval is at a time during the transmission of audio and 
video The first algorithm monitors the state of the network 1, at step 204, via the 
25 network monitor 22. At this time, the bit rate is an initial bit rate transmission, that 
is either a predetermined default rate, typically one set for a regular network state 
with sufficient quality audio, as in Fig. 4 in the Table, a bit rate of 12533 brts per 
second, corresponding to a network state of "Regular, with a quality state 
(quality degree) of "S« denoting sufficient audio quality, or the bit rate of the 
30 previous transmission (the most recent inteival). 

This network state monitoring may be with an RTCP Protocol. In 
accordance with that detailed in Standards Track-Rr-C 1 889. that is part of an 
H 323 protocol. As part of the protocol, a test packet may be transmitted over 
the network 1 , for example from transceiver 5 to transceiver 4, end back to the 
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transceiver 5. to measure parameters, such as packet loss and round trip time 
(RTD also known as round trip delay, the time It takes lor a packet to travel from 
the sending transceiver through the network and back to the sending transceiver . 
Packet loss and RTT are detailed in Standards Track-RFC 1 889. 

I he monitoring b such that the network monitor 22 Includes software and 
hardware for execufing an Cgorahm able to detect at least two differ** network 
states. This monitoring Is preferably continuous or at regular Intervals, typically 

at time lengths of 5 seconds. 

Once the network state Is detected (upon monitoring), the network rnonrtor 
22 sends data corresponding to the network etate to the allocator 21 . that 
abates data processing means in the allocator 21 or the body of 
means 10 that execute* an algorithm tor the audio, in accordance wrth the Table 
of Fig 4 where a G.723 codec is used. This first algorithm is euch that the 
network state, selected from four predetermined network states. Is closest to the 

15 detected network state. 

The network state is checked to see if it has changed, by the first 
algorithm, at step 206. The decision of network state change is done by 
detecting conditions at step 206, are detailed as follows: 

! ,f the measured packet loss is less than Z% and the present network 
state is "Loss" or "Loss plus Delay", the network state should be changed to 

either "Regular" or "Delay". 

2 If the current network state is "Regular" or "Delay" and measured 
packet loss is greater then 5%, and network state should be changed to W or 

"Loss plus Delay". 

3 If the current network stale is "Regular" or "Loss" and the measured 
round trip tjme (RTT) is greater then 1000ms, the network state should be 
changed to "Delay" or Toss plus Delay". 

4 When the current network state is "Delay" or "Loss plus Delay" and the 
measured RTT is less then 800ms. the network state should be changed to 

30 "Regular" or "Loss". 

If any of the above conditions have been detected, the network state has 
changed. The changed network state is matched to one of the four 
predetermined network states, and hit rate adjus^ent is made in accordance 
with the Table of Fig. 4. at step 208. for the predetermined network state, to 
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which the detected network state most closely corresponds. In making this first 
adju S tment.th e networkmonitor22signal S the a ilocator21. Inmakingth.* 
adjust, the algorithm attempts to achieve a uualKy state (quality degree) of 
,1 least Sufficient Quality or "S«. If the network state has not changed, th,s first 
bit rate adjustment is not made. This first algorithm is such that it attempts to 
achieve at least Sufficient Quality or «S» for the audio, so as to avoid changes of 
bit rate If possible. 

Turning back to the table of Fig. 4, the quality states (quality degrees) are 
detailed The "H" or High Quality state Is a monitored transmission of a packet, 
that includes a single audio frame for packets via tho IP communication protocol, 
for example, RFC 2198. If the transmission is made with redundancy. th.s 
redundant transmission indudes at least one redundant packet over the network 
with packet loss. Similarly, the or Sufficient Quality state is a momtored 
transmission of a packet, where 2-3 frames (audio) are packed into a packet v,a 
a protocol for redundancy (for example. RFC 2198), and redundancy is used 
when the network has packet loss. Other protocols, that help to overcome 
packet loss, such as forward error correction, are suitable for redundancy. 
Finally the "NS" or Non-sufficiont Quality state is a monitored transmission of a 
packetvia a protocol, for example, RhC 1889. that does not include the 
transmission of redundant packets, but results in packet loss in the transmiss,on. 

Next, a second algorithm is employed to check (monitor) for network 
congestion level or delay. Congestion or delay is detected based on RTCP 
reports as sent from the network monitor 22 to the allocator 21 . In this 
Algorithm, congestion is detected by analyzing three conditions, steps 220, 222 
and 224 If any of these conditions exist, the algorithm is such that brt rate .s 
decreased in a second or fine adjustment at step 226, by a signal to the allocator 
21 from the network monitor 22. If a condition does not exist, this second 
algorithm moves to the next condition to see if it has been met. These conditio 
are as follows: 

1 . Is packet loss on RTT above 30% (step 220): if YES. the bit rate .s 
decreased (step 226), It NO, the next condition (step 222) is analyzed; 

2. Has packet loss increased, typically by a rise of at least 4%. less than 
20 seconds after the bit rate was raised (step 222); if YES. the bil rate is 
decreased (step 226), if NO, the next condition (step 224) is analyzed; or 
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Has fte average RTT increased more then 70 msec, in a short tme. 
approbate* 20 second, (step 224): if YES. the bit rat. b decreased (step 
2 2« » NO. ft. next eendKon a,l three condfdon, do not ex... and the algorithm 

"""""Ln congestion In ft. network not detected. congestion over 
ft. last 20 seconds b checked at atop 230. If it has not bee,. " * 

Increased, b, a second or line adjustment a. step 232 in accordence with that 

detailed above. . . AU 

Congestion may aiso be caused by lack of available bandwidth on the 
network, that serves to M ft. H rate. In ftis case, M rate will be adjusted ,n 
ft, manner of the second or ^.adjustment, to .electa 8 
or "NS- from "H" or "8- respectively, in accordance with fte avertable network 
bandwidth. The network quality state is preferably adjusted to allow for 
transmlMionofatlea.ttwomediastrearns.typlc.llyaudioandv.deo. By 

Tnsnlng at ft.se iowerouain, states, particulady W, uansmlssion q ua.*y 
being sacrificed in view of the available bandwidth. 

If bit rate has been increescd at step 232 or if congestion ex,sted m the 
network over the last 20 seconds, the allocator 21. having been signaled to 
adjust bit rate, with both first (coarse) andfor second (fine) adjustments, the 
.0 second algorithm is now complete and the first algorithm is resumed. 

The continuation of this first algorithm is such that the audio and vdeo b* 
rat. controls 18. 20 respectively, are querbd forth, total bit rate between the 
audio and video channels, at step 2*0. During this step 240, at least one. and 
preferably both the audio and vid«. channels, are sampled by the aud,o 

25 sampling device 2 and video sampling devi« 23 respectively, in commumcatlon 
with ftoir respective b* rate controllers 19. 20. The allocator 21 MM. 
hardware and software that can detect the total bit rate by querying the tat rate ,n 
ft. audio and video bit rate controller. 19, 20 (as perthe audio an. I vrfoo 
channels .especUvely) and combing the bit rates to «nd fte total brt rate at tfep 

30 240. /^«^.ft.^^1*'^»^ -to ^ l 77 , ^; 

in accordane. with the Table of Fig. 4. Also, in accordance with the Table I F* 
4 ft. allocator 21 will know the total bit rate available, such that it can allocate tat 
rata between the audio and video bit rat. controllers 1 9. 20, at step 242. In 
making the allocation, priority will always be given to fte audio chenn.1. such that 
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the minimum bit rate forth, audio is in accordance with the bit rates of the table 

^ *' With the bR rote now determined for the audio, and the video. It video Is 
being emitted a* part of me multimedia call, a package can now be 

,n sending parameters, such . redundancy, of a. least one fame with each 
redundant packet, indicated in the Tab,, of Fk> 4 as 'Redund" and the number o, 
audio frames per packet, indicated in the Table of Fig. 4 as "FRff . 

Fta 6 shows a chart of hit rate vetsus frames (of audio) per packet for 
transmission, with a redundancy of 1 (line 260) and transmissions without 
redundancy (line 261). The chart of Fig. 7 details the actual bit rates for the 
transmissions with .edundancy in accordance wfth line 260 and without 
re dundancinaccordanoowithline261. When a redundant packet » 
transmuted, the redundant packet is preferably transmitted at a different protocol 
than the corresponding packet. For example, when the packet is transmitted ,,. a 
first protocol, typically the RFC 1889. the redundant packet will be transmitted ,n 
a different protocol, typically RFC 2198. 

With the packets composed, the transmission is made. Monitoring 
continues for as long as desired, typically for the entire period of the 
transmission, with the above detailed method repeated (steps 204 to 242). over 
the course of the transmission. The repetition is typically in accordance wilh the 
monitoring periods for the network. 

The entire apparatus disclosed above may be Implirnented on a data 
processor, such as a microprocessor (linked to a storage device). For example, 
client applications using these techniques may be implirnented under 
WINDOWS™ OS in Pentium based Personal Computers (PCs) with sound 
and/or video cards for audio and video processing respectively. 

While preferred embodiments of the present invention have been 
described so as to enable one of skill in the art to practice the present invent.cn, 
the preceding description is exemplary only, and should not be used to limit the 
scope of the invention. The scope of the invention should be determined by the 
following claims. 
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